packages/job-dispatch/src/new-target.ts (1)

Complete the target -> resource rename and update all dependencies

The function dispatchJobsForNewTargets needs to be renamed as suggested, and its imports need to be updated in multiple locations:

1. Rename packages/job-dispatch/src/new-target.ts to new-resource.ts and update its contents as suggested
2. Update imports in dependent files:
   • packages/job-dispatch/src/index.ts: Update export statement
   • packages/job-dispatch/src/target.ts: Update import statement
   • packages/api/src/router/environment.ts: Update import statement from @ctrlplane/job-dispatch

🔗 Analysis chain

Line range hint 11-24: Complete the target -> resource rename

To maintain consistency with the broader codebase changes, consider updating all "target" references in this file:

1. Rename the file to new-resource.ts
2. Update the function signature and implementation:

- export async function dispatchJobsForNewTargets(
+ export async function dispatchJobsForNewResources(
  db: Tx,
-  newTargetIds: string[],
+  newResourceIds: string[],
  envId: string,
): Promise<void> {
  const releaseJobTriggers = await createReleaseJobTriggers(db, "new_resource")
-    .targets(newTargetIds)
+    .targets(newResourceIds)
    .environments([envId])
    .insert();

3. Update the JSDoc comment:

/**
- * Dispatches jobs for new targets added to an environment.
+ * Dispatches jobs for new resources added to an environment.
 */

Let's verify if there are any imports of this file that would need updating:

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Find all files importing new-target.ts
rg -l "new-target" --type ts

Length of output: 99

---

Script:

#!/bin/bash
# Check how new-target.ts is imported in index.ts and target.ts
rg "new-target" --type ts -A 2 -B 2

Length of output: 741

---

Script:

#!/bin/bash
# Check usage of dispatchJobsForNewTargets in target.ts
ast-grep --pattern 'dispatchJobsForNewTargets($_)'

Length of output: 52

---

Script:

#!/bin/bash
# Check usage of dispatchJobsForNewTargets with more context
rg "dispatchJobsForNewTargets" --type ts -A 5 -B 5

Length of output: 3853

apps/webservice/src/app/api/v1/job-agents/[agentId]/jobs/running/route.ts (1)

Line range hint 8-13: Update schema imports to match new terminology

If the database schema has been renamed from target to resource, the imports should be updated accordingly.

Apply this change if the schema has been renamed:

import {
  deployment,
  environment,
  job,
  release,
  releaseJobTrigger,
- target,
+ resource,
} from "@ctrlplane/db/schema";

packages/db/src/schema/target-provider.ts (1)

Line range hint 1-1: File name should be updated to match new terminology

The file name target-provider.ts should be renamed to resource-provider.ts to maintain consistency with the new terminology.

apps/webservice/src/app/api/v1/target-providers/[providerId]/set/route.ts (1)

Line range hint 1-89: Incomplete refactoring of target -> resource

The file contains many remaining references to "target" that should be updated for consistency:

• File path: target-providers
• Imports: createTarget, targetProvider
• Schema references: targetProvider, createTarget
• Variable names: targetsToInsert, targets
• Function: upsertTargets

Consider:

1. Creating a tracking issue for the complete rename
2. Following a systematic approach:
   • Update schema first
   • Update imports and type references
   • Update API routes and endpoints
   • Update variable names
   • Update file/folder structure

Would you like me to help create a GitHub issue to track these remaining changes?

apps/webservice/src/app/api/v1/jobs/[jobId]/route.ts (2)

Line range hint 143-149: Update response structure for API consistency

The response structure still uses target in the final response object. This should be updated to maintain API consistency.

    return NextResponse.json({
      ...je.job,
      ...je,
      variables,
-     target: targetWithMetadata,
+     resource: targetWithMetadata,
      approval,
    });

---

Schema changes have been identified - table renamed from target to resource

The review comment's concern about database schema compatibility is valid. The recent migration (0035_moaning_supernaut.sql) shows a major schema change where the target table and all related tables have been renamed to use resource terminology:

• target → resource
• target_metadata → resource_metadata
• All related foreign key constraints and indexes have been updated accordingly

This change affects the code in question as it's still using the old terminology. The code needs to be updated to use the new schema names.

🔗 Analysis chain

Line range hint 127-134: Verify database schema compatibility

The code queries the targetMetadata table using the old terminology. Before proceeding with the refactoring, we should verify the database schema changes.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify database schema changes

# Check for schema definitions
echo "Checking for schema definitions..."
rg -A 5 "createTable.*target" --type ts
rg -A 5 "createTable.*resource" --type ts

# Check for migration files
echo "Checking for related migrations..."
fd -e sql -e ts --full-path "migration"

Length of output: 378

---

Script:

#!/bin/bash
# Let's try a different approach to find schema and migration related files

# Search for schema definitions using broader patterns
echo "Searching for schema definitions..."
rg -l "schema|table.*target|table.*resource" --type ts

# Look for Prisma schema files
echo "Looking for Prisma schema files..."
fd "schema.prisma"

# Search for specific database-related terms in the codebase
echo "Searching for database-related terms..."
rg -l "targetMetadata|target.*table" --type ts

# Check for any SQL or migration files
echo "Checking for migration files..."
fd -e sql

Length of output: 19531

---

Script:

#!/bin/bash
# Let's examine the schema files and migrations for target metadata related changes

# Check the target schema definition
echo "Checking target schema definition..."
cat packages/db/src/schema/target.ts

# Check recent migrations for any target metadata related changes
echo -e "\nChecking recent migrations..."
cat packages/db/drizzle/0035_moaning_supernaut.sql packages/db/drizzle/0036_furry_blue_marvel.sql

Length of output: 18074

packages/api/src/router/release-deploy.ts (1)

Line range hint 1-180: Complete the target → resource refactoring

The refactoring from "target" to "resource" seems incomplete. Consider updating:

1. Import statement: import { ..., target } from "@ctrlplane/db/schema"
2. Error messages: "Target not found" → "Resource not found"
3. Variable name: t → resource
4. Procedure name: toTarget → toResource

This would maintain consistency with the new terminology.

Here's a suggested refactor:

- import { ..., target } from "@ctrlplane/db/schema";
+ import { ..., resource } from "@ctrlplane/db/schema";

- toTarget: protectedProcedure
+ toResource: protectedProcedure

-      const t = await ctx.db
+      const resource = await ctx.db
         .select()
-        .from(target)
-        .where(eq(target.id, input.targetId))
+        .from(resource)
+        .where(eq(resource.id, input.targetId))
         .then(takeFirstOrNull);
-      if (!t) throw new Error("Target not found");
+      if (!resource) throw new Error("Resource not found");

-      if (t.lockedAt != null) throw new Error("Target is locked");
+      if (resource.lockedAt != null) throw new Error("Resource is locked");

packages/api/src/router/target-metadata-group.ts (1)

Line range hint 1-242: Consider database schema implications

The file contains multiple references to database tables and columns with the "target" prefix (e.g., targetMetadata, targetMetadataGroup). While this PR focuses on authorization types, the database schema will likely need to be updated in a future PR to maintain consistency with the new "resource" terminology.

Consider:

1. Planning the database schema migration strategy
2. Ensuring backward compatibility during the transition
3. Coordinating the changes with any ORM or query builder configurations

packages/db/src/schema/target.ts (6)

Line range hint 38-63: Ensure consistent renaming throughout the schema definition

While the table name has been changed to "resource", there are several references that still use the old "target" naming:

• Foreign key reference to targetProvider
• Variable name target in the code
• Types and schemas with 'Target' prefix

Consider updating these references for consistency:

-export const target = pgTable(
+export const resource = pgTable(
   "resource",
   {
     // ...
-    providerId: uuid("provider_id").references(() => targetProvider.id, {
+    providerId: uuid("provider_id").references(() => resourceProvider.id, {
     // ...
   }
 );

-export type Target = InferSelectModel<typeof target>;
+export type Resource = InferSelectModel<typeof resource>;

-export const createTarget = createInsertSchema(target, {
+export const createResource = createInsertSchema(resource, {

---

Line range hint 87-98: Update export constant name for consistency

The table name has been updated to "resource_schema", but the export constant still uses the old naming.

-export const targetSchema = pgTable(
+export const resourceSchema = pgTable(

---

Line range hint 100-116: Update view-related types and functions for consistency

While the table name has been updated to "resource_view", related types and functions still use the old naming:

• TargetView type
• TargetCondition type for the filter field
• createTargetView and updateTargetView functions

-export type TargetView = InferSelectModel<typeof targetView>;
+export type ResourceView = InferSelectModel<typeof resourceView>;

-export const createTargetView = createInsertSchema(targetView, {
-  filter: targetCondition,
+export const createResourceView = createInsertSchema(resourceView, {
+  filter: resourceCondition,
}).omit({ id: true });

-export const updateTargetView = createTargetView.partial();
+export const updateResourceView = createResourceView.partial();

---

Line range hint 119-128: Update metadata-related column names and functions

The table has been renamed to "resource_metadata", but several related elements still use the old naming:

• Column name "target_id"
• Relations and helper functions

export const targetMetadata = pgTable(
  "resource_metadata",
  {
    id: uuid("id").primaryKey().defaultRandom().notNull(),
-   targetId: uuid("target_id")
+   resourceId: uuid("resource_id")
      .references(() => resource.id, { onDelete: "cascade" })
      .notNull(),
    // ...
  }
);

-export const targetMetadataRelations = relations(targetMetadata, ({ one }) => ({
-  target: one(target, {
-    fields: [targetMetadata.targetId],
-    references: [target.id],
+export const resourceMetadataRelations = relations(resourceMetadata, ({ one }) => ({
+  resource: one(resource, {
+    fields: [resourceMetadata.resourceId],
+    references: [resource.id],
  }),
}));

-const buildMetadataCondition = (tx: Tx, cond: MetadataCondition): SQL => {
+const buildMetadataCondition = (tx: Tx, cond: MetadataCondition): SQL => {
   // Update references in the function body
   // ...
};

Also applies to: 134-196

---

Line range hint 232-257: Update relationship-related column names and types

While the table and enum names have been updated, several elements still use the old naming:

• Column names "source_id" and "target_id"
• Types and functions with "Target" prefix

-export const targetRelationshipType = pgEnum("resource_relationship_type", [
+export const resourceRelationshipType = pgEnum("resource_relationship_type", [
  "associated_with",
  "depends_on",
]);

-export const targetRelationship = pgTable(
+export const resourceRelationship = pgTable(
  "resource_relationship",
  {
    id: uuid("id").primaryKey().defaultRandom(),
-   sourceId: uuid("source_id")
-     .references(() => target.id, { onDelete: "cascade" })
+   sourceId: uuid("source_id")
+     .references(() => resource.id, { onDelete: "cascade" })
      .notNull(),
-   targetId: uuid("target_id")
-     .references(() => target.id, { onDelete: "cascade" })
+   destinationId: uuid("destination_id")
+     .references(() => resource.id, { onDelete: "cascade" })
      .notNull(),
-   type: targetRelationshipType("type").notNull(),
+   type: resourceRelationshipType("type").notNull(),
  },
);

-export const createTargetRelationship = createInsertSchema(targetRelationship).omit({ id: true });
+export const createResourceRelationship = createInsertSchema(resourceRelationship).omit({ id: true });

-export const updateTargetRelationship = createTargetRelationship.partial();
+export const updateResourceRelationship = createResourceRelationship.partial();

-export type TargetRelationship = InferSelectModel<typeof targetRelationship>;
+export type ResourceRelationship = InferSelectModel<typeof resourceRelationship>;

---

Line range hint 260-285: Update variable-related column names and types

The table has been renamed to "resource_variable", but several elements still use the old naming:

• Column name "target_id"
• Types and functions with "Target" prefix

export const targetVariable = pgTable(
  "resource_variable",
  {
    id: uuid("id").primaryKey().defaultRandom(),
-   targetId: uuid("target_id")
-     .references(() => target.id, { onDelete: "cascade" })
+   resourceId: uuid("resource_id")
+     .references(() => resource.id, { onDelete: "cascade" })
      .notNull(),
    // ...
  }
);

-export const targetVariableRelations = relations(targetVariable, ({ one }) => ({
-  target: one(target, {
-    fields: [targetVariable.targetId],
-    references: [target.id],
+export const resourceVariableRelations = relations(resourceVariable, ({ one }) => ({
+  resource: one(resource, {
+    fields: [resourceVariable.resourceId],
+    references: [resource.id],
  }),
}));

-export const createTargetVariable = createInsertSchema(targetVariable, {
+export const createResourceVariable = createInsertSchema(resourceVariable, {
  value: z.union([z.string(), z.number(), z.boolean()]),
}).omit({ id: true });

-export const updateTargetVariable = createTargetVariable.partial();
+export const updateResourceVariable = createResourceVariable.partial();

-export type TargetVariable = InferSelectModel<typeof targetVariable>;
+export type ResourceVariable = InferSelectModel<typeof resourceVariable>;

packages/db/drizzle/0036_furry_blue_marvel.sql (1)

7-19: Consider reordering operations for safer migration.

While the renaming is consistent, consider reordering the operations to:

1. Drop foreign key constraints first
2. Perform table/column renames
3. Recreate constraints and indexes

This order minimizes the risk of dependency-related issues during migration.

packages/db/src/schema/environment.ts (1)

41-43: Consider a comprehensive rename strategy

The current change only renames the database column while retaining the old terminology in types (TargetCondition), imports (@ctrlplane/validators/targets), and validation functions (isValidTargetCondition). Consider:

1. Updating type definitions to use "resource" terminology
2. Creating new validation functions with updated names
3. Deprecating old types/functions with a migration period
4. Updating API contracts if this field is exposed

This will ensure consistency across the entire codebase.

packages/auth/src/utils/rbac.ts (2)

211-211: Systematic naming inconsistency across scope handlers

The inconsistency between "target" and "resource" terminology appears systematic across multiple handlers. A comprehensive refactoring is needed to ensure consistency across:

1. Function names
2. Database schema references
3. Return types

Consider using a migration strategy:

1. Update database schema first
2. Create new functions with "resource" naming
3. Deprecate old functions
4. Update all references
5. Remove deprecated functions

Also applies to: 225-225

---

Line range hint 1-396: Incomplete refactoring needs comprehensive approach

The current changes only update return types to use "resource" terminology while leaving function names and database schema references using "target". This partial refactoring could lead to:

1. Runtime errors due to mismatched property access
2. Maintenance confusion due to mixed terminology
3. Potential issues in type checking and IDE support

Recommend:

1. Create a tracking issue for the complete refactoring
2. Document all places requiring updates (functions, schemas, types)
3. Plan the migration in stages to maintain backward compatibility
4. Add tests to verify the refactoring doesn't break existing functionality

packages/api/src/router/deployment-variable.ts (1)

295-295: Complete the target -> resource refactoring

While the authorization check update from "target" to "resource" aligns with the PR objectives, there's an inconsistency as the procedure name byTargetId and its implementation still use the "target" terminology. Consider completing the refactoring for consistency.

Apply these changes to maintain consistent terminology:

-  byTargetId: protectedProcedure
+  byResourceId: protectedProcedure

Also, consider updating the related database queries and variable names from target to resource in a follow-up PR to maintain consistency throughout the codebase.

packages/api/src/router/deployment.ts (1)

Line range hint 1-500: Consider using a systematic refactoring approach

The current changes show an incomplete transition from "target" to "resource" terminology. To ensure consistency and prevent bugs, consider:

1. Using a systematic approach to identify all occurrences
2. Creating a migration plan that includes:
   • Database schema changes
   • API endpoint updates
   • Documentation updates
   • Test updates
3. Using TypeScript's type system to catch inconsistencies

Would you like help creating a comprehensive checklist for this refactoring effort?

Configuration used: .coderabbit.yaml
Review profile: CHILL

Learnt from: adityachoudhari26
PR: ctrlplanedev/ctrlplane#181
File: packages/api/src/router/deployment.ts:116-131
Timestamp: 2024-11-10T20:33:41.576Z
Learning: In `packages/api/src/router/deployment.ts`, the `list.byDeploymentId` procedure requires multiple database queries due to limitations of the `releaseMatchesCondition` function.

Learnt from: adityachoudhari26
PR: ctrlplanedev/ctrlplane#181
File: packages/auth/src/utils/rbac.ts:102-118
Timestamp: 2024-11-10T20:33:41.576Z
Learning: The `releaseChannel` scope type is included in the `scopeType` enum in `packages/db/src/schema/rbac.ts`.

#!/bin/bash
# Description: Find usages of the current type names to assess the scope of the change

echo "Checking TypeScript/JavaScript files for usages:"
rg -l "targetMetadataGroup|TargetMetadataGroup" --type ts --type js

#!/bin/bash
# Description: Check for migration file containing the table rename
# Expected: Find a migration file with ALTER TABLE statement

rg -l 'ALTER TABLE.*target_metadata_group.*TO.*resource_metadata_group' --type sql

#!/bin/bash
# Let's check for migration files in common locations
fd -e sql migration

# Also check for any SQL files containing table rename patterns
rg -l 'RENAME TABLE|ALTER TABLE.*RENAME' --type sql

#!/bin/bash
# Let's check the content of these migration files, focusing on the most recent ones first
cat packages/db/drizzle/0036_furry_blue_marvel.sql
cat packages/db/drizzle/0025_low_talisman.sql

#!/bin/bash
# Check for any files importing these types/variables that would need updates
rg "import.*\{.*(targetProvider|TargetProvider).*\}" --type ts

#!/bin/bash
# Check for any remaining references to the old column name
rg "target_provider_id" --type ts

#!/bin/bash
# Check for migration files that handle this table rename
fd -e sql -e ts migration | rg -l "target_provider.*resource_provider"

#!/bin/bash
# Let's try a more comprehensive search for migration files
fd migration

# Then search for any files containing target_provider or resource_provider
rg -l "target_provider|resource_provider"

#!/bin/bash
# Look for Prisma schema files
fd schema.prisma

# Check for other common migration tool configurations
fd -e flyway.conf -e liquibase.properties -e dbmate.yml

#!/bin/bash
# Get the content of the target-provider schema file
cat packages/db/src/schema/target-provider.ts

#!/bin/bash
# Let's check the latest migration file that might contain the rename
cat packages/db/drizzle/0036_furry_blue_marvel.sql

# Also check the content of the target.ts schema to understand the relationship
cat packages/db/src/schema/target.ts

#!/bin/bash
# Description: Check for other API routes that might need path updates
# and verify the impact of potential route path changes

# Find all route.ts files in the API directory
fd route.ts apps/webservice/src/app/api

# Check for "targets" in route paths
rg -l "targets" apps/webservice/src/app/api

#!/bin/bash
# Check GKE-related files for consistent terminology
echo "Checking GKE-related files..."
rg -A 5 "getGkeTargets|GkeTarget" --type ts

# Check for any remaining Google provider references
echo "Checking Google provider references..."
rg -A 5 "provider_google|ProviderGoogle" --type ts

#!/bin/bash
# Check for remaining "target" references in the codebase
echo "Files still using 'target' in paths:"
fd -t f target

echo "\nCode still using 'target' in schema and queries:"
rg 'schema\.target|query\.target'

echo "\nPermission enums still using 'Target':"
rg 'Permission\.Target'

export const createDeploymentVariableValue = createInsertSchema(
  deploymentVariableValue,
-  { targetFilter: targetCondition },
+  { resource_filter: targetCondition },
)

#!/bin/bash
# Description: Check for any remaining references to targetFilter and related database queries

# Check for any remaining references to targetFilter
rg -l "targetFilter"

# Check for SQL migrations related to this change
fd -e sql -e ts -p "migration|migrate" -x rg -l "targetFilter|resource_filter" {}

# Check for related query implementations
ast-grep --pattern 'select($$$).from($$$).where({ targetFilter: $$$ })'

#!/bin/bash
# Check for migration files in the db package
fd -e sql -e ts migration packages/db/src -x cat {}

# Check for specific schema definitions and queries using resource_filter
rg -A 5 "resource_filter"

# Look for Drizzle schema definitions related to this column
ast-grep --pattern 'jsonb("resource_filter")'

#!/bin/bash
# Description: Verify the migration file exists and contains the target->resource renaming

# Check if the migration file exists
fd --type f "0036_furry_blue_marvel.sql" packages/db/drizzle

# Check the content of the migration file for target->resource renaming
rg -i "target|resource" $(fd --type f "0036_furry_blue_marvel.sql" packages/db/drizzle)

#!/bin/bash
# Check if this pattern of partial renaming is consistent across other files
rg -A 2 "type: \"resource" packages/api/src/router/

#!/bin/bash
# Check for any remaining "targetMetadataGroup" or similar authorization types
rg -i 'type: "target' packages/api/src/router/

#!/bin/bash
# Search for other authorization type references to ensure consistency
rg --type typescript "type: \"(target|resource)Provider\"" -B 2 -A 2

# Check Permission enum definition
ast-grep --pattern 'enum Permission {
  $$$
  TargetList
  $$$
}'

#!/bin/bash
# Search for authorization type references with proper typescript extension
rg --type ts "type: \"(target|resource)Provider\"" -B 2 -A 2

# Check Permission enum definition in typescript files
rg --type ts "enum Permission" -A 10

#!/bin/bash
# Let's see more of the Permission enum to find target-related permissions
rg --type ts "enum Permission" -A 30

# Also check for any remaining "targetProvider" references that might need updating
rg --type ts "targetProvider" -B 2 -A 2

#!/bin/bash
# Search for any remaining references to old enum values
rg -i "new_target|target_changed" --type ts

#!/bin/bash
# Let's verify the usage of the new enum values to ensure they are properly used
rg -i "new_resource|resource_changed" --type ts -A 2 -B 2

#!/bin/bash
# Let's check if there are any inconsistencies in file names or paths still using "target"
fd target

#!/bin/bash
# Check for related migration files
fd -e sql . | xargs rg "resource_filter|target_filter"

# Look for potentially affected queries
rg "targetFilter|resource_filter" --type typescript -B 2 -A 2

#!/bin/bash
# Description: Search for usages of the releaseRouter.list procedure and any references to its response structure

# Search for direct usage of the list procedure
echo "Searching for direct usage of releaseRouter.list..."
rg -l "releaseRouter\W+list|useQuery.*list" --type ts

# Search for any type definitions or interfaces that might include this structure
echo "Searching for type definitions that might need updates..."
ast-grep --pattern 'interface $name {
  $$$
  target: $type
  $$$
}'

# Search for test assertions that might be affected
echo "Searching for test files that might need updates..."
rg -l "\.target\W" --type test

#!/bin/bash
# Let's try a more comprehensive search strategy

# 1. Search for any files that might be consuming the release router
echo "Searching for files importing or using release router..."
rg -l "from.*router/release|releaseRouter" --type typescript

# 2. Search for interface definitions related to releases
echo "Searching for release-related interfaces..."
rg -l "interface.*Release|type.*Release" --type typescript

# 3. Search for test files specifically
echo "Searching for release-related test files..."
fd -e test.ts -e spec.ts | xargs rg -l "target"

# 4. Search for any usage of target property in typescript files
echo "Searching for usage of target property..."
rg -l "\.target\b" --type typescript

#!/bin/bash
# Adjust search with correct file type 'ts' instead of 'typescript'

# 1. Search for any files that might be consuming the release router
echo "Searching for files importing or using release router..."
rg -l "from.*router/release|releaseRouter" --type ts

# 2. Search for interface definitions related to releases
echo "Searching for release-related interfaces..."
rg -A 5 "interface.*Release|type.*Release" --type ts

# 3. Look at the context of target usage in the found test files
echo "Examining target usage in test files..."
rg -C 3 "target" packages/job-dispatch/src/__test__/job-variables-deployment.test.ts integrations/terraform-cloud-scanner/src/__tests__/scanner.test.ts

# 4. Search for any usage of target property in ts files
echo "Searching for usage of target property..."
rg -l "\.target\b" --type ts

#!/bin/bash
# Let's examine the specific usage of 'target' in the release router and related files

# 1. Look at the release router implementation
echo "Examining release router implementation..."
rg -C 5 "target: j\.resource" packages/api/src/router/release.ts

# 2. Look at the root router where release router is used
echo "Examining root router..."
rg -C 5 "releaseRouter" packages/api/src/root.ts

# 3. Look for any direct consumers of the list procedure
echo "Looking for consumers of list procedure..."
rg -C 5 "useQuery.*list.*release" --type ts apps/

# 4. Check for any type definitions that might be affected
echo "Checking type definitions..."
rg -C 5 "type.*Release.*\{" packages/api/src/router/release.ts

#!/bin/bash
# Search for complex queries involving target/resource
rg -B 5 -A 5 "\.innerJoin\(target," --type ts

#!/bin/bash
# Description: Check if the database schema has been updated consistently
# Look for remaining references to 'target' in schema definitions

# Check schema definitions
rg -g "schema.ts" "target.*=.*defineTable"

# Check if there are any pending migrations
fd -g "*.sql" -t f

#!/bin/bash
# Check recent migrations for any table/column renames
rg -l "target|resource" packages/db/drizzle/00{34,35,36}*.sql | xargs cat

# Check schema definitions for both target and resource
rg -g "schema.ts" -A 5 "resource.*=.*defineTable|target.*=.*defineTable"

# Check the specific query implementation
rg -B 5 -A 5 "distributionById.*=.*" packages/api/src/router/deployment.ts

#!/bin/bash
# Check the distributionById query implementation
rg -C 10 "distributionById" packages/api/src/router/deployment.ts

# Check for any remaining references to 'target' table in the codebase
rg -g "*.ts" "from.*target.*join|join.*target"

#!/bin/bash
# Description: Search for any remaining instances of old authorization types

echo "Checking for any missed 'type: \"target\"' occurrences:"
rg 'type:\s*"target"' --type ts

echo "Checking for any missed 'type: \"targetView\"' occurrences:"
rg 'type:\s*"targetView"' --type ts

#!/bin/bash
# Let's examine the context of these remaining occurrences to determine if they are related to authorization

echo "Checking context of remaining 'type: \"target\"' occurrences:"
rg 'type:\s*"target"' --type ts -B 5 -A 5

# Also check for any other authorization-related code near these files
echo "Checking for authorization patterns in the same files:"
rg 'canUser|Permission|authorizationCheck' apps/webservice/src/app/\[workspaceSlug\]/_components/target-drawer/relationships/RelationshipsDiagram.tsx apps/webservice/src/app/\[workspaceSlug\]/_components/job-drawer/RelationshipsDiagramDependencies.tsx

#!/bin/bash
# Description: Check for API documentation and version changes

# Check for changelog updates
fd CHANGELOG -e md | xargs rg -l 'target.*resource'

# Check for version bump in package.json
fd package.json | xargs rg '"version":'

#!/bin/bash
# Description: Check if database schema has been updated to reflect the target to resource renaming

# Check for any remaining references to 'target' in schema files
fd -e ts -e sql . | xargs rg -l 'createTable\("target"|TABLE\s+target\b'

# Check for new 'resource' table definitions
fd -e ts -e sql . | xargs rg -l 'createTable\("resource"|TABLE\s+resource\b'

#!/bin/bash
# Let's check for database schema changes more specifically

# Check schema files for target/resource table definitions and migrations
echo "=== Checking schema files ==="
rg -A 5 "createTable\(.*target" packages/db/src/schema/
rg -A 5 "createTable\(.*resource" packages/db/src/schema/

echo "=== Checking recent migration files ==="
# Look at recent migration files for table renames or structure changes
fd -e sql . packages/db/drizzle/ | sort -r | head -n 5 | xargs cat

echo "=== Checking type definitions ==="
# Check type definitions to understand the data structure
rg -A 3 "type.*Target" packages/db/src/schema/
rg -A 3 "type.*Resource" packages/db/src/schema/

#!/bin/bash
# Description: Check for consistent authorization type changes

# Check for any remaining "target" type in authorization checks
rg -l 'type:\s*"target"' -g '*.ts'

# Check for new "resource" type usage in authorization checks
rg -l 'type:\s*"resource"' -g '*.ts'

# Check authorization utilities for type definitions
ast-grep --pattern 'type\s+ResourceType\s*=.*"resource".*'

#!/bin/bash
# Check the actual usage context of "type" in authorization checks
rg 'type:\s*"(?:target|resource)"' -A 2 -B 2 --color never

# Check for any type definitions or enums related to these types
ast-grep --pattern 'type $_AuthType = {
  $$$
}'

packages/job-dispatch/src/policies/release-dependency.ts (1)

Line range hint 42-69: Consider optimizing the recursive CTE

While the renaming changes look good, the recursive CTE could benefit from some optimizations:

1. The CASE expressions are repeated multiple times
2. The visited array grows with each recursion

Consider this optimization:

  WITH RECURSIVE reachable_relationships(id, visited, tr_id, source_id, target_id, type) AS (
    -- Base case: start with the given ID and no relationship
    SELECT 
        ${trigger.targetId}::uuid AS id, 
        ARRAY[${trigger.targetId}::uuid] AS visited,
        NULL::uuid AS tr_id,
        NULL::uuid AS source_id,
        NULL::uuid AS target_id,
        NULL::resource_relationship_type AS type
    UNION ALL
    -- Recursive case: find all relationships connected to the current set of IDs
    SELECT
-       CASE
-           WHEN tr.source_id = rr.id THEN tr.target_id
-           ELSE tr.source_id
-       END AS id,
-       rr.visited || CASE
-           WHEN tr.source_id = rr.id THEN tr.target_id
-           ELSE tr.source_id
-       END,
+       COALESCE(NULLIF(tr.target_id, rr.id), tr.source_id) AS id,
+       rr.visited || COALESCE(NULLIF(tr.target_id, rr.id), tr.source_id),
        tr.id AS tr_id,
        tr.source_id,
        tr.target_id,
        tr.type
    FROM reachable_relationships rr
    JOIN resource_relationship tr ON tr.source_id = rr.id OR tr.target_id = rr.id
    WHERE
-       NOT CASE
-           WHEN tr.source_id = rr.id THEN tr.target_id
-           ELSE tr.source_id
-       END = ANY(rr.visited)
+       NOT COALESCE(NULLIF(tr.target_id, rr.id), tr.source_id) = ANY(rr.visited)
        AND tr.target_id != ${trigger.targetId}
)

This optimization:

1. Reduces repeated CASE expressions using COALESCE and NULLIF
2. Maintains the same logic but with better readability
3. May improve performance by reducing expression evaluations

packages/api/src/router/target.ts (3)

125-125: Consider updating router and schema names for consistency

While the authorization check types have been updated from "targetView" to "resourceView", the router name (targetViews) and schema references still use the old terminology. Consider updating these for consistency:

• Rename targetViews router to resourceViews
• Update schema references from targetView to resourceView

Also applies to: 142-142, 154-154

---

205-205: Update variable naming for consistency

While the authorization check types have been updated to use "resource", the variable references still use targetId. Consider updating these references for consistency:

• Rename targetId to resourceId in variable references
• Update schema references from targetVariable to resourceVariable

Also applies to: 231-231, 261-261

---

Line range hint 1-574: Consider a more systematic refactoring approach

The current changes focus mainly on authorization check types, but a more systematic approach to the target->resource renaming would be beneficial:

1. Create a comprehensive migration plan that includes:

   • Schema updates (tables, foreign keys)
   • Router names
   • Variable names
   • Event handlers
   • Job-related functionality

2. Consider using a codemod or automated refactoring tool to ensure consistent renaming across the codebase.

3. Add tests to verify that the refactoring doesn't break existing functionality.

Configuration used: .coderabbit.yaml
Review profile: CHILL

#!/bin/bash
# Description: Verify the database table renaming consistency
# Expected: All references should use resource_relationship, not target_relationship

# Check for any remaining references to the old table name
rg "target_relationship([^_]|$)"

# Check for migration files that handle this rename
fd -e sql -e ts . | rg -l "RENAME TABLE.*target_relationship.*TO.*resource_relationship"

#!/bin/bash
# Description: Check for schema changes and type usage
# Test: Look for metadata table references in schema
rg -A 5 "resource_metadata|target_metadata" --type ts

# Test: Check for similar type definitions that might be reused
rg "type.*Record<string,\s*string>" --type ts

#!/bin/bash
# Description: Check for related functionality that might be affected
# Test: Look for event handlers and job-related functions
rg "getEventsForTarget|ReleaseJobTrigger" --type ts

# Test: Check for other routers that might need similar updates
rg "createTRPCRouter.*target" --type ts

ALTER TABLE "target_relationship" RENAME TO "resource_relationship";

export const targetRelationship = pgTable(
  "resource_relationship",
  {
    // ...
  }
);

#!/bin/bash
# Description: Check for schema migration files and verify table existence
# Test: Look for migration files containing table rename
fd --type f . | rg -i "migration.*resource_relationship"

# Test: Check if both old and new tables exist in schema definitions
rg -A 5 "resource_relationship|target_relationship" --type ts

#!/bin/bash
# Let's search for schema definitions and migrations related to resource/target relationships
# Look for schema definitions
rg "relationship.*schema" --type ts -A 5

# Look for table definitions in schema files
fd schema -t f | xargs rg "createTable.*relationship" -A 10

# Look for migrations
fd migrations -t d | xargs rg "relationship" -A 5

packages/api/src/router/deployment.ts (1)

Line range hint 1-524: Consider documenting the target->resource refactoring strategy

The current changes appear to be part of a larger refactoring effort to rename "target" to "resource". However, the changes are inconsistent across the file, with some places updated while others retain the old terminology. This could lead to confusion and maintenance challenges.

Consider:

1. Documenting the refactoring strategy and timeline
2. Creating a tracking issue for all required changes
3. Using a consistent approach (either update everything at once or clearly mark what's pending)
4. Adding comments to explain any intentionally mixed terminology during the transition

Configuration used: .coderabbit.yaml
Review profile: CHILL

-  byTargetId: protectedProcedure
+  byResourceId: protectedProcedure

#!/bin/bash
# Check for procedure usage across the codebase
rg "byTargetId" -g "*.ts" -A 3

# Check for other potential target->resource renames needed
ast-grep --pattern 'byTargetId($$$)' -l ts

packages/api/src/router/target.ts (1)

310-312: Consider renaming the router for consistency

While the authorization check updates from "target" to "resource" are correct, consider renaming targetRouter to resourceRouter for consistency with the new terminology.

-export const targetRouter = createTRPCRouter({
+export const resourceRouter = createTRPCRouter({

Also applies to: 418-418, 477-477, 523-523, 540-540, 558-558

Configuration used: .coderabbit.yaml
Review profile: CHILL